home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19981211-19990422 / 000023_news@newsmaster….columbia.edu _Fri Dec 18 11:41:29 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA27861
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 18 Dec 1998 11:41:28 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA28791
  7.     for kermit.misc@watsun; Fri, 18 Dec 1998 11:41:28 -0500 (EST)
  8. Newsgroups: comp.protocols.kermit.misc
  9. Path: news.columbia.edu!panix!cam-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.xcom.net!ix.netcom.com!gerlach
  10. From: gerlach@netcom.com (Matthew H. Gerlach)
  11. Subject: Re: receiving straight binary
  12. Message-ID: <gerlachF46656.2yF@netcom.com>
  13. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  14. References: <gerlachF4602I.IDE@netcom.com> <75dsph$4i1$1@apakabar.cc.columbia.edu>
  15. Date: Fri, 18 Dec 1998 16:36:42 GMT
  16. Lines: 51
  17. Sender: gerlach@netcom15.netcom.com
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9655
  19.  
  20. In article <75dsph$4i1$1@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  21. >In article <gerlachF4602I.IDE@netcom.com>,
  22. >Matthew H. Gerlach <gerlach@netcom.com> wrote:
  23. >: I have a device that spits out raw binary serial data, and I want it to go
  24. >: to a harddrive.  I'm using 6.1.193 Beta.05 on a Solaris machine.  What I
  25. >: did was write a small program that reads stdin and writes it to a file.  I
  26. >: then used the ckermit "redirect" command to run my program attaching the
  27. >: serial input stream to my program's stdin.
  28. >: 
  29. >: I'm sure there is a better way to do this, but I'm not sure what that better
  30. >: way is.  I have written scripts using the "input" command that does
  31. >: the same thing for ascii text, but I'm not sure it would work too well
  32. >: in the this case.
  33. >: 
  34. >There's no reason why it shouldn't:
  35. >
  36. >  set line /dev/tty0 ; or whatever
  37. >  set speed 19200    ; or whatever
  38. >  set parity none
  39. >  set flow rts/cts   ; or none -- not xon/xoff
  40. >  set session-log binary
  41. >  set terminal byte 8
  42. >  set terminal character-set transparent
  43. >  log session
  44. >  input 9999 termination-sequence
  45. >  close session
  46. >
  47. >The trick is to know when to stop logging, but you must have had some
  48. >criterion in your stdin/stdout program so you should be able to use the
  49. >same one here.
  50. >
  51. >- Frank
  52.  
  53.  
  54. The termination criteria is the trick.  Currently, my stdin/stdout program
  55. has no "stopping criteria".  It stops when I signal it.  From the "input"
  56. command's point of view, the data stream is random; so there is no
  57. pattern to "look for".  I just want to "input" the bytes and log them.
  58. For the record, the data stream is a Mu-law encoded audio stream.
  59.  
  60. Thinking about this more.  What I have is a burst of data coming out of the 
  61. device.  So a convenient script would wait a certain amount of time
  62. for anything to come over the wire, log it, and when there is large pause
  63. in the data stream, say a second or so, it would stop.
  64.  
  65. Looking at the "input" command in the manual some more, if I just give
  66. it a timeout and no text it will wait for any single character.  I suppose
  67. this would work, but I'm running at 115k, and it seems "input"ing 
  68. single characters might be rather expensive processing-wise.
  69.  
  70. Matthew